In all business domains and transactions, capture of data is done through electronic forms that customarily store data in tables related to forms. A form in that sense, is more or less, a window of the End User to the database table. Usually the tables are designed by mapping business transactions to software objects in what is known as object oriented programming (OOP).
To build an object oriented program, there is a prolonged phase of analysis of the business domain and business transactions, by an expert information engineer, to optimize the architecture to meet End User requirements.
GUI designers strive to meet multi End User needs of access to multiple forms representing business objects, and try to do this in the least possible number of GUI instances i.e. forms/menus/buttons. However, when business objects are numerous due to specific and detailed requirements of the business, this often leads to many forms/menus with visually overloaded designs. As a result, complicated GUI requires significant training and long usage before achieving a satisfactory return on time investment of both the End User and the organization.
Furthermore, if End User requirements change for any reason, adopting that change requires always analysis of the new requirements, integration with the changes with previous design, and certainly significant code writing and back-end changes in the database. Often times, such changes are hard to obtain because they have a significant financial and logistic overhead. End Users usually try to live with the shortcomings of the software even though this would impact productivity.
An Object Oriented Program targets a specific business domain with specific End User needs. In a multidisciplinary enterprise, different End User requirements lead to the creation of multiple applications; however, enterprises need certainly includes queries that span information acquired in more than one application; and interconnecting those applications to meet those needs resulted in the creation of what is known as ERP systems—Enterprise Resource Planning applications—ERP systems transact with a single database serving several applications with many tables. ERP programs are out of the reach of small to medium sized enterprises, entail significant initial programming, and exhausting End User training. Even so, any change of End User requirements means significant programming and integration overhead.
There is still room for improvement in the art. Therefore, it is the object of the present invention to provide a software engine that enables end users to design, create and use an unlimited number of different types of forms, reports, and queries over a computer network. The advantage the present invention provides over current systems is that the database definition does not restrict forms, so that an increase in the number of forms does not affect the structure of the database. The schema definition of the backend database is static regardless of the number or structure of forms that operate and transact against it, and users of the current invention do not have to write any programming code to upsize or change the application.